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ABSTRACT 

Software  Engineering  environments  have  to  support  design  methodologies 
whose  main  activity  is  not  the  generation  of  new  independent  programs,  but 
the  maintenance,  integration,  modification  and  explanation  of  existing  ones. 
Especially  for  software  systems  in  ill-structured  problem  domains  where 
detailed  specifications  are  not  available  (like  Artificial  Intelligence  and 
Human-Computer  Communication),  incremental,  evolutionary  redesign  has 
to  be  efficiently  supported. 

To  achieve  this  goal  we  have  designed  and  constructed  an  object-oriented, 
knowledge-based  user  interface  construction  kit  and  a  large  number  of 
associated  tools  and  intelligent  support  systems  to  be  able  to  exploit  this  kit 
effectively.  Answers  to  the  “user  interface  design  question’’  are  given  by 
providing  appropriate  building  blocks  that  suggest  the  way  user  interfaces 
should  be  built.  The  object-oriented  system  architecture  provides  great 
flexibility,  enhances  the  reusability  of  many  building  blocks,  and  supports 
redesign.  Because  existing  objects  can  be  used  either  directly  or  with  minor 
modifications,  the  designer  can  base  a  new  user  interface  on  standard  and 
well-tested  components. 


1.  Introduction 

Human-computer  communication  and  knowledge-based  systems  are  two 
research  domains  consisting  mostly  of  ill-structured  problems.  In  these 
domains  it  is  seldom  possible  to  provide  a  precise  specification  of  intent; 
and  without  this  specification,  correctness  is  in  general  not  a  meaningful 
question.  The  main  difficulty  is  not  "correct"  implementation  of  given 
specifications,  but  development  of  specifications  that  lead  to  effective  solu¬ 
tions  corresponding  to  real  needs.  In  [Fischer,  Schneider  84]  we  argued  that 
life  cycle  models  are  inadequate  for  ill-structured  problems  and  should  be 
replaced  by  incremental  design  and  a  rapid  prototyping  methodology  based 
on  a  communication  model.  Construction  kits  and  support  tools  that  allow 
the  exploration  of  alternatives  can  considerably  enhance  this  approach. 

Redesign  is  a  methodology  which  achieves  that  the  prototyping  process  is 
rapid  and  it  allows  us  to  explore  design  alternatives  for  a  problem.  In 
addition,  it  supports  that  existing  systems  can  be  adapted  to  new  require¬ 
ments  and  can  be  tailored  to  special  needs  of  individual  users  and  user 
communities.  Our  redesign  methodology  is  based  on  a  construction  kit  (see 
Figure  2-1)  which  provides  as  building  blocks  the  abstractions  expected  to 
be  relevant  for  exploring  the  design  space.  In  the  domain  of  human- 
computer  communication  and  user  interfaces,  primitives  such  as  windows, 
menus,  icons  and  editors  are  the  basis  for  specific  applications.  Over  the 
last  six  years  we  have  designed,  implemented  and  continuously  enhanced  a 
system  for  this  domain  called  wlisp  [Fabian  86,  Boecker,  Fabian,  Lemke 
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85]*.  wlisp’s  flexibility  as  a  construction  kit  is  provided  by  its  object- 
oriented  architecture.  It  contains  a  large  amount  of  knowledge  about  the 
design  of  user  interfaces.  Additional  knowledge  is  represented  in  support 
systems  that  guide  the  design  process  and  critique  intermediate  results. 

An  especially  interesting  feature  of  wlisp  is  that  it  is  one  of  the  few  systems 
implemented  in  a  time  sharing  environment.  It  is  currently  running  in 
FranzLisp  and  ObjTalk  [Rathke  86]  on  VAX  systems  using  powerful  ter¬ 
minals  and  is  not  restricted  to  high  performance  personal  computers.  This 
environment  provided  both  the  necessity  and  the  opportunity  for  im¬ 
plementing  a  distributed  architecture  between  terminal  and  main  frame. 

From  a  designer’s  viewpoint,  WLISP  provides  a  visually  baser!,  interactive 
programming  environment  [Barstow,  Shrobe,  Sandewall  84],  WLISP  has 
been  an  everyday  operational  environment  at  a  number  of  institutions 
within  universities  and  research  organizations  for  several  years.  WLISP  has 
served  the  designers  of  user  interface  software  as  well  as  the  end-users. 

Figure  1-1  describes  our  vision  of  the  architecture  of  an  intelligent  design 
environment.  This  architecture  is  based  on  the  belief  that  the 
“intelligence”  of  a  complex  tool  must  contribute  to  its  ease  of  use.  Truly 


The  system  was  named  WLISP  because  its  development  began  8  years  ago  with  the  goal  of 
providing  a  window-based  programming  environment  for  lisp. 
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intelligent  and  knowledgeable  humans,  such  as  good  teachers,  use  a  sub¬ 
stantial  part  of  their  knowledge  to  explain  their  expertise  to  others.  In  the 
same  way,  the  “intelligence”  of  a  computer  system  should  be  used  to 
provide  effective  communication.  We  have  built  prototypical  systems  in 
many  areas  of  the  outer  circle:  documentation  systems  [Fischer,  Schneider 
84],  help  systems  [Fischer,  Lemke,  Schwab  85],  critics  [Fischer  87],  and 
visualization  tools  [Boecker,  Fischer,  Nieper  86], 


3.2)  and  support  tools  (e.g.,  the  browser;  see  Section  4.1)  are  steps  in  the 
direction  of  making  it  easier  to  modify  an  existing  system  than  to  create  a 
new  one.  Inheritance  is  important  for  redesign  because  it  enables  objects 
that  are  almost  like  other  objects  to  be  created  easily  with  a  few  incremental 
changes.  Inheritance  reduces  the  need  to  specify  redundant  information  and 
simplifies  updating  and  modification  by  allowing  information  to  be  entered 
and  changed  in  one  place. 


In  die  following  sections  we  illustrate  the  redesign  process  with  a  case 
study,  describe  the  wusp  system  and  a  prototypical  design  support  tool 
(TRIKJT)  and  evaluate  the  strengths  and  weaknesses  of  our  approach.  In  the 
last  section  we  briefly  describe  ideas  for  future  developments. 


2.  From  Design  to  Redesign 

Many  large  software  systems  are  built  as  in  Figure  2-1-a;  a  monolithic 
system  is  completely  implemented  in  a  general  purpose  programming  lan¬ 
guage.  Although  these  systems  are  usually  structured  in  some  way,  this 
structure  is  oriented  only  towards  the  original  specification  of  the  problem. 
To  overcome  the  difficulty  of  redesign  that  has  been  experienced  with  these 
systems,  the  design  of  one  (or  more)  intermediate  levels  of  abstractions 
must  be  an  integral  part  of  the  software  process  (Figure  2-1 -b).  This 
strategy  allows  for  both  easy  redesign  by  modifying  the  original  design 
(Figure  2-1-c)  and  reuse  by  recombining  the  intermediate  abstractions  to 
form  a  different  system  (Figure  2-1-d). 

Software  Engineering  environments  of  the  future  have  to  support  design 
methodologies  whose  main  activity  is  not  the  generation  of  new,  inde¬ 
pendent  programs,  but  the  integration,  modification,  and  explanation  of  ex¬ 
isting  ones  [Winograd  79].  Just  as  one  relies  on  already  established 
theorems  in  a  new  mathematical  proof,  new  systems  should  be  built  as 
much  as  possible  using  existing  parts.  In  order  to  do  so,  the  designer  must 
understand  the  functioning  of  these  parts.  An  important  question  concerns 
the  level  of  understanding  necessary  for  successful  redesign:  exactly  how 
much  does  the  user  have  to  understand?  Our  methodologies  (differential 
programming  and  programming  by  specialization  [Kay  84]  based  on  our 
object-oriented  knowledge  representation  language  ObjTalk;  sec  Section 
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Figure  2-1:  Reuse  and  redesign 


A  construction  kit  with  a  large  number  of  generally  useful  building  blocks 
provides  a  good  basis  for  redesign.  Simon  [Simon  81]  demonstrates  that  the 
evolution  of  a  complex  system  proceeds  much  faster  if  stable  intermediate 
parts  exist.  The  abstractions,  represented  in  wusp  by  more  than  200 
ObjTalk  classes,  comprise  stable  intermediate  parts  for  development  of  user 
interfaces.  The  large  number  of  classes  in  wusp  is  a  mixed  blessing.  The 
advantage  is  that  in  all  likelihood  a  building  block  or  set  of  building  blocks 
that  either  fits  our  needs  or  comes  close  to  doing  so  already  exists  and  has 
already  been  used  and  tested.  The  disadvantage  is  that  they  are  useless 
unless  the  designer  knows  that  they  are  available.  Informal  experiments 
[Fischer  87]  indicate  that  the  following  problems  prevent  designers  from 
successfully  exploiting  the  potential  of  high  functionality  systems: 

•  designers  do  not  know  about  the  existence  of  needed  objects 
(either  building  blocks  or  tools); 

•  designers  do  not  know  how  to  access  objects; 

•  designers  do  not  know  when  to  use  these  objects; 

•  designers  do  not  understand  the  results  objects  produce  for 
them; 

•  designers  cannot  combine,  adapt  and  modify  an  object  for  their 
specific  needs. 

Unless  we  are  able  to  solve  these  problems,  designers  will  constantly  rein¬ 
vent  the  wheel  instead  of  taking  advantage  of  already  existing  tools. 


3.  Description  of  WLISP 

Our  ideas,  models  and  theories  about  the  design  of  human-computer  inter¬ 
faces  have  become  operational  with  the  development  of  WUSP.  The  struc¬ 
ture  of  the  wusp  system  defines  a  way  of  looking  at  and  dealing  with  user 
interfaces.  For  users  it  provides  a  consistent  world  in  which  they  can 
transfer  interaction  techniques  among  applications.  For  designers  it 
provides  a  set  of  basic  building  blocks  from  which  they  can  choose  in 
designing  a  specific  application. 


3.1.  A  User’s  View 

As  a  whole,  wlisp  can  be  described  as  a  world  with  which  the  user  interacts 
by  screen  manipulation.  The  system  is  reactive  in  the  sense  that  each  object 
on  the  screen  exhibits  a  certain  type  of  behavior.  Actions  that  change  the 
common  world  of  user  and  system  can  be  invoked  either  by  the  system 
(e.g„  by  updating  some  information  about  the  stale  of  an  application)  or  by 
the  user  (e.g.,  by  selecting  some  command  from  a  menu).  The  designer 
using  WUSP  or  the  user  of  a  specific  application  system  deals  with  screen 
objects  such  as  windows,  icons,  menus  and  buttons  (see  Figure  3-1),  that  arc 
manipulated  using  the  mouse  as  a  pointing  device.  Many  screen  objects  are 
independent  of  specific  applications  and  serve  as  basic  building  blocks  for 
different  applications. 

The  user’s  view,  which,  depending  on  the  task,  is  either  that  of  a  software 
engineer  or  an  end-user  is  shown  in  a  typical  screen  image  of  wlisp  Figure 

•  At  the  top  of  the  screen  some  status  information  is  shown.  It 
is  is  updated  continually  by  the  underlying  UNIX  operating  sys¬ 
tem.  The  status  line  displays  time,  load  average,  and  number  of 
users  and  tells  about  incoming  and  pending  mail. 

•  A  LISP  interpreter  is  running  in  the  toplevel  window.  Cur¬ 
rently  it  displays  the  ObjTalk-Definition  of  a  character  object. 

On  the  right-hand  side  of  the  toplevel  window  a  static  menu  is 
visible. 

•  Different  systems  can  be  activated  by  selecting  the  appropriate 
icon  from  the  Catalog.  The  Catalog  tells  users  which  systems 
are  available. 
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Figure  3-1:  The  user’s  view  of  wlisp 


•  At  the  bottom  of  the  screen  a  Character-Editor  window  is 
shown  that  supports  the  definition  of  icons.  All  icons  on  the 
screen  have  been  defined  with  the  Character-Editor. 

•  A  window-menu  is  associated  with  each  window.  It  contains 
the  basic  operations  on  windows.  Pressing  a  mouse  button 
inside  a  window  activates  a  pop-up  menu  with  operations  for 
the  application  itself.  In  the  Character-Editor  this  menu  dis¬ 
plays  operations  to  manipulate  the  pixel  image  of  die  character 
object. 

•  Some  of  these  operations  are  also  accessible  through  buttons 
on  the  right  margin.  Menus  and  buttons  are  alternative  ways  to 
perform  die  same  operations. 

•  The  directory-editor  window  gives  access  to  the  UNIX  file  sys¬ 
tem.  It  contains  files  of  a  certain  directory. 

•  The  Catalog  and  the  Character-Editor  windows  have  scroll 
bars  on  their  right  and  lower  sides.  Windows  in  general  show 
only  a  rectangular  part  of  some  larger  region.  Scrolling  means 
to  move  this  region  below  the  window. 

•  Windows  can  be  shrunk  to  icons  when  they  are  not  needed. 
Some  of  diem  are  shown  on  die  right  side.  Icons  are  visual 
reminders  of  systems,  functions  and  windows.  They  are  or¬ 
ganized  in  clusters  that  determines  their  spatial  layout. 


•  In  the  mouse-documentation-window  at  the  bottom  of  the 
screen  information  about  mouse  actions  is  displayed.  As  the 
user  moves  the  mouse  over  windows,  buttons  or  icons,  this 
information  is  updated. 

The  association  of  applications  with  windows  allows  for  an  arbitrary  num¬ 
ber  of  applications  to  run  at  the  same  Ume.  The  user  has  direct  access  to 
each  of  them.  WLISP  provides  a  means  for  their  integration. 


3.2.  A  Designer’s  View 

The  components  of  wlisp  are  implemented  in  ObjTalk,  an  object-oriented 
knowledge  representation  language  [Rathke  86].  Control  is  expressed  in 
terms  of  a  message  passing  among  objects  [Hewitt  77].  Objects  behave 
based  on  the  interpretation  of  messages  and  their  internal  state. 

Objects  are  organized  in  classes.  Objects  of  the  same  class  -  the  instances 
of  that  class  -  have  the  same  methods  ahd  slots  and  show  the  same  type  of 
behavior.  Classes  are  arranged  in  hierarchies.  They  share  the  properties 
(i.e.,  methods  and  slots)  of  their  parent  classes.  In  this  way  properties  are 
inherited  by  classes.  All  classes  together  form  an  inheritance  hierarchy 
with  a  special  class  at  the  root  called  object.  The  fundamental  properties 
of  all  objects  are  defined  in  object.  They  can  be  modified  or  extended  in 
any  of  its  subclasses. 
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Figure  3-3:  The  tristan  classes 


All  components  of  WLISP  are  organized  in  inheritance  hierarchies  of  classes. 
Classes  describe  screen  objects  such  as  windows  or  menus  and  components 
of  screen  objects  such  as  borders,  titles  and  buttons. 

The  design,  development  and  use  of  WLISP  have  shown  that  the  object- 
oriented  architecture  together  with  well  established  components  and  build¬ 
ing  blocks  are  extremely  useful  for  the  design  of  user  interfaces,  wlisp 
classes  provide  a  set  of  abstractions  on  which  the  designer  can  rely.  Exist¬ 
ing  systems  like  menus,  icons,  the  directory  editor,  the  character-editor,  and 
the  catalog  serve  as  examples  for  the  construction  new  user  interfaces.  The 
object-oriented  architecture  supports  the  reuse  of  components  and  building 
blocks. 


Four  categories  of  wlisp  system  classes  can  be  identified: 

1.  Basic  system  classes.  These  classes  describe  rectangular 
areas  on  the  screen  such  as  regions,  borders  and  titles.  They 
are  combined  to  construct  output  windows,  text  windows  or 
dialogue  windows.  Superwindows  act  on  subscreens,  which 
can  contain  multiple  subwindows.  The  inheritance  hierarchy 
of  the  basic  system  classes  is  shown  in  Figure  3-2. 

2.  Basic  components  of  the  user  interface  construction  kit. 
These  classes  form  the  application-independent  parts  of  the 
user  interface.  Menus,  icons,  buttons,  scroll  bars,  etc.  inherit 
properties  from  the  basic  system  classes.  Parts  of  them  can 
also  be  used  as  building  blocks  for  application  systems. 

3.  Advanced  components  of  the  user  interface  construction 
kit.  tristan  [Nieper  85]  is  an  example  of  a  complex  com¬ 
ponent  providing  high-level  abstractions  for  displaying  and 
editing  graph  structures  through  direct  manipulation. 

Figure  3-3  shows  the  elements  of  tristan  as  applied  to  a 
graphic  UNIX  directory  editor,  tristan  is  independent  of  the 
particular  node  representation.  It  assumes  only  that  the  node 
representation  is  a  subclass  of  the  simple-display- 
region  window  class. 

4.  Application  systems.  Application  systems  use  the  com¬ 
ponents  of  the  interface  construction  kit  in  different  ways. 
Menus,  icons,  buttons  or  dialogue  windows  can  be  used 
directly  within  an  application  system.  Other  classes  serve  as  a 
source  from  which  properties  are  inherited.  Applications 
usually  define  their  own  classes  that  incorporate  the  existing 
functionality  by  inheritance. 

The  reuse  of  wlisp  system  classes  by  means  of  inheritance  and  combination 
is  supported  by  the  object-oriented  architecture: 

•  The  creation  of  subclasses  of  existing  classes  allows  the  desig¬ 
ner  to  create  new  objects  that  differ  from  existing  objects  in 
some  desired  aspects  (e.g.,  different  methods  for  some  mes¬ 
sages,  additional  slots)  but  that  inherit  almost  all  of  tire 
functionality  of  their  ancestors. 

•  The  use  of  predefined  components  is  not  an  all-or-nothing  deci¬ 
sion.  If  the  component  has  one  undesired  property,  this  com¬ 
ponent  need  not  be  completely  abandoned.  Even  if  the  be¬ 
havior  of  a  superclass  is  to  a  very  large  extent  undesired,  it  can 
still  be  used  by  shadowing  all  but  the  useful  properties. 
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•  Subclasses  are  not  modified,  independent  copies  of  their  super¬ 
classes.  They  benefit  from  any  augmentations  of  their  super¬ 
classes. 

•  Extensions  can  be  done  on  different  levels  of  the  hierarchy, 
thereby  affecting  selected  classes  of  objects. 

•  Like  other  object-oriented  languages,  ObjTalk  supports 
dynamic  modification  of  classes.  Slots  can  be  added  without 
recompilation  of  other  software.  This  not  only  makes  rapid 
prototyping  easier  but  also  supports  modifications  by  the  end 
user. 

•  Each  method  can  be  a  hook  for  modifying  behavior.  Methods 
can  be  augmented  by  adding  procedures  to  be  executed  before, 
after,  or  instead  of  existing  methods. 

These  architectural  principles  support  new  programming  methodologies 
such  as  differential  programming  and  programming  by  specialization  and 
analogy,  which  is  crucial  to  a  redesign  approach  to  system  development. 
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4.  A  Case  Study  in  Redesign 

In  this  section  we  describe  a  prototypical  task,  the  redesign  of  the  interface 
to  the  ObjTalk  Browser  [Rathke  86]  and  how  problems  in  redesigning  this 
interface  were  solved  by  exploiting  the  architectural  properties  of  wusp. 


4.1.  The  ObjTalk  BROWSER 

To  accomplish  our  main  goal,  which  is  to  facilitate  the  redesign  of  software 
and  avoid  building  it  from  scratch,  information  retrieval  tools  for  reusable 
software  components  like  ObjTalk  classes  have  become  an  absolute  neces¬ 
sity.  Browsers  have  become  increasingly  valuable  for  understanding  and 
changing  systems.  They  displace  program  listings  because  they  present  a 
program  as  a  multidimensional  structure  being  generated  and  filtered 
dynamically.  In  SMALLTALK  [Goldberg  84],  the  browser  is  the  main  inter¬ 
face  to  the  system  and  is  used  both  for  finding  and  analyzing  existing  pieces 
of  software  and  for  modifying  and  creating  new  software.  It  replaces  the 
file  system  and  the  editor  of  conventional  systems.  The  interaction  style  is 
one  of  moving  and  searching  through  an  information  space  rather  than 
directly  accessing  the  space  through  names  or  descriptions. 

The  WLISP  BROWSER  displays  the  inheritance  structure  of  a  system.  The 
interconnections  between  the  system  and  the  components  it  inherits  from 
can  be  analyzed  in  more  detail  by  selecting  a  component  and  looking  at  its 
slot  descriptions,  defaults,  triggers,  and  methods  (Figure  4-1). 

The  browser  exhibits  some  of  the  more  advanced  interface  characteristics 
provided  by  WLISP.  The  main  window  is  divided  into  several  subwindows 
whose  relationship  is  automatically  maintained  by  wltsp  and  displayed  in 
paned  windows.  Inside  the  Classes  Window  ObjTalk  classes  can  be 
visualized  by  icons  and  are  connected  by  arrows  to  show  the  superclass 
relationship.  Selecting  a  class  icon  causes  the  other  BROWSER  windows  to 
be  filled  with  slots,  methods,  subclasses  and  instances  of  that  class.  This 
feature  is  implemented  using  the  constraint  mechanism  of  ObjTalk. 


4.2.  Description  of  the  Redesign  Process 

The  BROWSER  had  undergone  several  redesigns  before  it  took  its  current 
shape.  In  an  earlier  development  stage  classes  were  represented  as  items  of 
a  scrollable  menu  (Figure  4-2).  We  describe  the  process  of  redesigning  the 
menu-based  browser  to  show  iconic  representations  for  ObjTalk  classes 
instead. 

The  Task.  Instead  of  classes  being  visualized  by  strings  in  a  scrollable 
menu,  we  would  like  to  display  classes  as  icons  that  are  connected  by 
arrows  to  show  tire  superclass  relationship.  Everything  else  should  stay 
unchanged,  especially  the  dependencies  between  tire  selected  class  and  the 
contents  of  the  other  windows. 

The  Redesign.  The  class  of  the  window  to  be  replaced  (BROWSER-CLASSES- 
MENU)  has  two  superclasses  (Figure  4-3):  BROWSER -SELECTION-MEX IN  and 
CLASSES-MENU.  BROWSER-SELECTION-MIXIN  provides  BROWSER-CLASS F.S- 
MENU  with  the  application-dependent  knowledge.  It  describes  how  the 
consequences  of  a  class  selection  are  propagated  to  the  other  browser 
windows.  CLASSES-MENU  provides  BROWSER-CLASSES-MENU  with  the 
knowledge  for  scrolling  and  menu  selection.  The  redesign  consists  of 


Figure  4-1:  The  BROWSER  with  windows  to  show  the  class 
hierarchy,  methods,  slots,  instances  and  subclasses 
of  a  selected  class 
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Figure  4-2:  The  original  BROWSER 


Figure  4-3:  The  inheritance  hierarchy  of  BROWSER-CLASSES-MENU 


replacing  this  class  by  a  new  one,  thereby  maintaining  the  important  inter¬ 
active  properties  of  selecting,  adding  and  deleting  classes. 

In  order  to  find  out  about  the  desired  properties  of  the  new  class  we  hike  a 
closer  look  at  the  definition  of  browser-classes-menu  (Figure  4-3): 

SCROLL-MENU  is  combined  with  CLASSES-MENU-MIXIN  to  form  the  CLASSES- 
MENU  class.  Windows  of  this  class  are  able  to  display  classes  as  strings. 
BROWSER-CLASSES-MENU  is  constructed  by  mixing  BROWSER-SELECTION- 
MEXIN  in  with  CLASSES-MENU. 


U+Q&XB 


In  BROWSER-SELECTION-MIXEN  the  dependencies  between  the  selected  class 
and  die  other  browser  windows  are  represented:  Whenever  a  class  is 
selected,  the  contents  of  these  windows  will  be  updated  to  display  methods, 
slots,  subclasses  and  instances  of  the  selected  class.  Because  this 
functionality  is  not  to  be  changed,  we  can  use  BROWSER-SELECTION-MIX  IN 
without  any  modifications. 

Instead  of  scroll -menu  we  use  simple-window  as  the  basis  for  the  new 
window.  Simple  windows  provide  the  basic  window  capabilities  of  graphi- 
cal  windows  in  which  icons  can  be  placed  and  lines  can  be  drawn.  It  sets  up 
a  coordinate  system  with  its  origin  at  the  lower  left  comer.  Scrolling  the 
contents  of  a  simple  window  is  interpreted  as  moving  the  origin  of  the 
graphic  coordinate  system.  CLASSES-MENU-MIX1N  is  replaced  by  a  new 
mixin  class  (class-net-WINDOW-MIXIN)  that  specifies  methods  for  selec¬ 
tion,  addition  and  deletion  of  classes.  These  operations  are  different  from 
the  ones  in  the  preexisting  implementation  because  they  now  have  to  dis¬ 
play,  add  and  delete  icons  and  connect  them  by  arrows  (Figure  4-4). 


Figure  4-4:  The  inheritance  hierarchy  of  BROWSER-NET-WINDOW 
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Figure  5-1:  Initial  state  of  the  main  form  and  an 

inheritance  hierarchy  window  generated  from  it 


The  implementation  of  the  functionality  for  CLASS-NET- window -mixin 
would  be  a  difficult  task  if  there  were  no  support  for  manipulating  icons  that 
contain  text  and  that  are  connected  by  lines.  Icons  are  an  integrated  part  of 
the  wlisp  system.  There  are  components  that  deal  with  text  manipulation 
within  icons  (c.g.,  hyphenation  and  adjustment  to  the  horizontal  and  vertical 
center),  borders  of  various  shapes  and  selection  feedback.  Also,  the 
capability  of  connecting  icons  by  arrows  is  supplied  by  a  number  of  classes 
from  wlisp’s  net  package. 

As  the  Final  step,  the  new  class  class  net-window-MIXIN  is  combined  with 
simple-window  to  form  class-net -window.  Together  with  browser- 
SELECTION-MKIN  the  final  browser-net- window  is  constructed  (Figure 
4-4). 


5.  Intelligent  Support  Tools  for  Reuse  and  Redesign 
In  addition  to  suitable  languages  and  system  architectures,  support  systems 
are  necessary  to  enhance  reuse  and  redesign  processes.  Rich  computing 
environments  contain  at  least  hundreds  of  components  that  can  be  combined 
in  many  different  ways.  The  existence  of  a  component  alone  does  not 
guarantee  that  it  is  readily  available  and  that  its  usefulness  is  apparent. 
Therefore,  support  tools  are  needed  that  have  knowledge  about  the  structure 
of  systems  and  about  the  use  of  existing  facilities,  that  aid  in  making  design 
decisions,  carry  out  low  level  details,  analyze  or  criticize  intermediate  ver¬ 
sions,  and  visualize  their  structure.  We  will  call  these  support  tools  design 
kits. 

In  this  section  we  describe  trikit  as  an  example  of  this  type  of  systems  (for 
a  detailed  description  see  [Fischer,  Lemke  87]).  TRIKIT  supports  design  and 
redesign  of  network  displays  and  editors.  With  its  knowledge  of  this  task 
domain  it  can  aid  the  designer  by  automatically  offering  interesting  design 
choices,  selecting  appropriate  components,  and  combining  them  to  make  a 
functioning  system.  The  designer  needs  much  less  knowledge  and  is  able  to 
produce  higher  quality  results  in  shorter  time. 


The  display  and  modification  of  hierarchical  and  network  structures  is  a 
common  problem  in  application  systems  including  those  that  deal  with 
structures  of  databases,  directory  trees,  inheritance  hierarchies,  or  depen¬ 
dency  graphs  are  examples.  TRISTAN,  the  user  interface  component 
described  in  Section  3.2,  is  a  large  set  of  object-oriented  construction  com¬ 
ponents  that  is  applicable  to  many  different  types  of  graphical  represen¬ 
tations.  .We  have  used  it  to  graphically  display  UNIX  file  system  hierarchies, 
inheritance  networks  in  object-oriented  languages,  and  dependency  relation¬ 
ships  between  rules  in  rule-based  expert  systems. 

trikit  is  a  design  kit  for  combining  the  TRISTAN  components  with  a 
specific  application.  It  presents  itself  to  the  user  as  a  collection  of  inter¬ 
action  sheets  as  shown  in  Figures  5-1  (top  window)  and  5-2.  On  these 
interaction  sheets  the  designer  specifies  the  interface  to  the  application.  The 
designer  specifies  in  terms  of  the  application  what  it  means  to  create  and 
delete  a  node  or  to  insert  and  remove  a  link.  Here  the  designer  chooses  the 
desired  graphical  representation  for  the  nodes  of  the  graph  and  controls  the 
creation  of  the  user  interface.  This  design  process  is  carried  out  above  the 
code  level.  TRIKIT  hides  from  the  designer  program  code  that  is  generated 
when  the  network  editor  is  created  or  modified. 

Initially,  the  form  is  filled  in  with  an  example  application  -  an  ObjTalk 
inheritance  hierarchy  viewer;  the  window  at  the  bottom  of  Figure  5-1  shows 
an  instance.  This  allows  users  to  familiarize  themselves  with  TRIKIT  and  to 
modify  parameters  and  explore  their  significance.  The  system  supports 
redesign  by  providing  designers  with  prototypical  solutions  and  allowing 
them  to  take  advantage  of  as  much  previous  work  and  knowledge  as  pos¬ 
sible. 

Designers  using  TRIKIT  need  to  know  very  little  about  the  TRISTAN  com¬ 
ponent.  However,  they  do  need  to  fill  in  code  to  access  the  application,  for 
example,  to  retrieve  the  nodes  of  the  graph,  or  to  signal  events  that  changed 
it.  In  addition  to  the  specification  of  the  application  interface,  many  options 
of  TRIKIT  can  be  controlled.  The  representation  of  different  types  of  nodes 
of  the  graph  (different  fonts,  sizes,  the  use  of  pictorial  representations)  or 
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Figure  5-2:  Initial  slate  of  the  node  form 

describing  properties  of  individual  nodes. 


the  layout  direction  (horizontal  or  vertical)  can  be  adjusted  to  an  individual 
application.  Although  the  design  space  is  limited  by  the  available  options  in 
the  forms,  it  is  still  possible  to  use  this  system  to  create  a  prototype  to  be 
further  refined  on  a  lower  level  (ObjTalk). 

We  have  preferred  a  form-based  specification  over  a  specification  language 
because  form-based  specification  does  not  require  the  user  to  learn  a  lan¬ 
guage  in  order  to  be  able  to  use  the  tool.  An  alternative  that  we  will  explore 
further  is  a  direct  manipulation  interface  [Hutchins,  Holian,  Norman  86]. 
However,  the  abstract  nature  of  many  parameters  (e.g.,  access  functions  for 
nodes,  layout  direction,  distinguishing  characteristics  of  node  types)  may 
make  a  direct  manipulation  interface  infeasible. 


6.  The  Evolutionary  Development  of  Wiisp 

The  development  of  the  wlisp  system  itself  has  been  an  incremental  evolu¬ 
tionary  process  in  which  redesign  has  played  a  crucial  role.  It  began  many 
years  ago  with  the  implementation  of  a  window  system,  and  new  interface 
components  have  been  added  incrementally.  Ideas  for  further  development 
and  enhancement  originated  from  the  following  sources: 

•  Systems  constructed  with  an  existing  version  of  wlisp  led  to 
the  development  of  new  features  that  were  at  first  built  from 
scratch,  quite  often  by  different  persons.  Subsequently,  the 
general  usability  of  these  features  was  recognized,  and  new, 
general  components  were  built  and  integrated  into  wlisp. 

•  There  was  a  strong  interplay  between  the  development  of  new 
applications  and  the  recognition  of  the  shortcoming  of  the 
available  construction  blocks  and  tools.  For  example,  there 
was  a  long-felt  need  for  superwindows  and  paned  windows. 

Many  applications  resulted  in  special  solutions  until  our  under¬ 
standing  was  good  enough  to  develop  them  as  general  classes. 

•  Other  developments  of  similar  systems  were  carefully  analyzed 
(e.g.,  the  SMALLTalk  system,  the  Macintosh,  the  LISP 
machines,  expert  system  shells  like  KEE,  ART  and  LOOPS). 

We  believe  that  this  evolutionary  process  has  led  to  a  set  of  abstractions, 
represented  as  classes  in  an  inheritance  network,  that  represent  “tools  of 
thought”  for  die  designer  and  a  "weak  theory”  of  user  interfaces.  Using 
the  current  kit  guarantees  the  development  of  reasonable  interfaces  with 
modest  efforts  and  supports  a  redesign  methodology. 

Even  today,  the  inheritance  lattice  of  WLISP  components  is  not  static. 
Changes  such  as  moving  classes  up  in  the  lattice  or  isolating  certain  charac¬ 
teristics  in  separate  mixins  to  increase  the  amount  of  shared  information, 
reflect  our  growing  understanding  of  the  hierarchical  structure  and  decom¬ 
position  of  a  problem  domain.  The  development  of  WLISP  demonstrates  that 
ill-structured  problem  domains,  such  as  user  interface  and  AI  programming 
[Fischer,  Schneider  84],  require  the  coevolution  of  specification  and  im¬ 
plementation  to  achieve  adequate  and  useful  solutions  [Swartout,  Balzer 
82], 


7.  Evaluation 

Observing  designers  in  dealing  widi  complex  software  systems,  one  can  see 
that  they  do  not  engage  in  redesign  processes  (even  if  they  would  like  the 
system  to  behave  differently)  because  redesign  is  not  supported  well 
enough.  The  effort  to  change  a  system  or  to  explore  design  alternatives  is 
too  expensive  in  most  software  production  environments.  Our  experience 
with  our  systems  and  tools  makes  us  believe  that  if  the  cost  of  making 
changes  is  cheap  enough,  designers  will  start  to  experiment  thereby  gaining 
experience  and  insight  leading  to  belter  designs.  The  existence  of  editors 
and  formatting  systems  has  shown  that  the  willingness  of  writers  to  modify 
existing  solutions  increases. 

Reuse  and  redesign  processes  in  our  environment  are  supported  by  WLISP 
and  tools  like  the  browser  and  trikit.  The  reaction  of  designers  using  these 
tools  has  been  largely  positive,  and  a  large  number  of  complex  systems  with 
different  user  interfaces  have  been  built  (e.g.,  the  NEWTON-Interface 
[Rathke  87]).  The  increased  willingness  to  redesign  has  led  to  the  con¬ 
struction  of  systems  which  fit  an  environment  of  needs.  We  feel  very 
strongly  that  the  specification  of  graphical,  dynamic  interfaces  with  a  static, 
linear  description  language  has  severe  limitations.  Interfaces  have  a  feel 
and  an  aesthetic  quality  that  have  to  be  experienced  and  that  cannot  be 
derived  formally  from  specification  languages.  We  were  able  to  study 
empirically  the  consequences  of  specific  design  choices.  Systems  that  make 
use  of  wlisp’ s  abstractions  are  relatively  easy  to  modify,  maintain  and 
adapt  to  changing  needs.  The  object-oriented  architecture  provides  a  much 
greater  flexibility  and  range  of  application  than  traditional  subroutine 
libraries,  which  have  failed  as  tools  for  redesign  and  reuse,  because  they  are 
filled  with  specific  implementations  [Balzer,  Cheatham,  Green  83]. 

We  are,  however,  aware  of  problems  that  remain  to  be  solved.  As  described 
in  Section  2,  knowing  about  the  existence  of  components  is  not  trivial, 
especially  as  the  number  of  available  components  is  growing.  In  Section  4 
it  remains  unclear  how  the  components  for  building  CLASS-NET-WINDOW- 
MIXIN  have  been  determined.  One  can  only  search  for  something  if  one 
knows  that  something  like  it  might  exist. 

If  one  has  found  a  potentially  useful  component,  one  has  to  determine  how 
it  has  to  be  used  and  combined  with  the  other  components.  One  has  to 
understand  its  functionality  and  its  properties.  Design  kits  such  as  TRIKIT 
are  an  attempt  at  solving  this  problem.  The  problem  of  understanding, 
however,  remains.  The  fields  of  trikit’s  forms  use  a  certain  terminology, 
which  not  everybody  is  familiar  with.  The  design  space  that  is  supported  by 
trikit  must  be  extended  to  make  it  a  more  generally  applicable  tool. 

We  need  more  active  tools  or  agents  that  have  sufficient  self-knowledge  to 
offer  their  services.  Our  active  help  system  [Fischer,  Lemke,  Schwab 
85]  and  our  critic  [Fischer  87]  are  other  steps  in  the  direction  of  filling  this 
need. 


8.  Conclusions 

To  cope  with  the  ever-increasing  complexity  of  designing,  conslmcting, 
maintaining  and  enhancing  software  products,  we  have  to  replace  discipline 
(by  the  software  engineer)  with  better  tools.  A  formalized,  computer- 
assisted  software  paradigm  must  supersale  the  current  informal,  person- 
based  software  paradigm. 

We  believe  that  we  have  made  an  important  step  towards  this  goal.  The 
classes  of  WLISP  reflect  our  understanding  of  how  to  decompose  the  domain 
of  modern  user  interfaces.  WLISP  contains  many  building  blocks  allowing 
existing  software  to  a  be  reused  and  supporting  design  by  redesign.  Intel¬ 
ligent  support  tools  guide  the  user  in  selecting  among  the  numerous  build¬ 
ing  blocks.  Part  of  the  knowledge  about  required  or  useful  combinations 
about  these  components  can  be  represented  within  WLISP  itself.  In  further 
development  stages  of  wlisp  we  will  formalize  die  experts*  knowledge 
about  the  use  of  components  in  ObjTalk  meta-classes.  Meta-classes  allow 
the  representation  of  structural  and  behavioral  properties  of  classes.  For 
instance,  the  ObjTalk  classes  that  describe  paned  windows  (Figure  4-1)  are 
instances  of  a  special  meta-class  WPANE  that  automatically  supplies  its 
instances  with  a  required  set  of  superclasses. 

Design  for  Redesign  is  a  promising  mediodology  for  keeping  software 
"soft"  and  preventing  it  from  becoming  ossified  and  brittle  with  age. 
Modification  within  our  methodology  is  not  automated,  but  it  is  greatly 
facilitated.  Redesign  of  software  is  similar  to  interior  design  of  buildings. 


where  contexts  and  boundaries  are  given:  in  our  case  contexts  and  boun¬ 
daries  are  provided  by  the  components  of  the  construction  kit.  Made  with 
this  approach,  incremental  improvements  will  be  cheap  enough  that 
software  engineers  can  experiment  with  alternative  implementations, 
thereby  gaining  experience  and  insight  leading  to  better  designs. 


[Hutchins,  Hollan,  Norman  86] 

E.L.  Hutchins,  J.D.  Hollan,  D.  A.  Norman,  Direct  Manipulation 
Interfaces ,  in  D.A.  Norman,  S.W,  Draper  (cds.),  User  Centered 
System  Design,  New  Perspectives  on  Human-Computer 
Interaction,  Lawrence  Erlbaum  Associates,  Inc.,  Hillsdale,  NJ, 
1986,  pp.  87-124,  ch.  5. 
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